Due to the explosion in the use of the Internet in recent years, there has been a huge increase in the exchange and storage of electronic data over the Internet. This data comes in files of all types and in messages. Many systems have been designed to provide management functionality for this data, including transfer systems (including e-mail, file transferring systems, etc) and storage systems, including single “owner” or shared storage, as well as providing other functionality such as moving remote files, renaming, etc. In general, it may be allowed that these systems work quite well and are adopted by millions of users, except where the user feels security of his data is an important issue. Many prospective users do not trust the Internet as a place where data can be placed privately and confidentially.
One way of securing data being transferred is by encryption. Many “secure” file transfer systems use e-mail technology (smtp) or web-based (http) e-mail. But, in fact, e-mail is quite unsuitable as a medium for the transfer of large files and this is recognized in many systems, which must limit the file sizes, which their users are allowed to transfer. Typically, the file must be sent as an attachment and is limited to 1-8 megabytes in size, depending on the system used. Sometimes, the systems can only purport to encrypt the message itself, not the attachment, and the attachment must be encrypted by separate freestanding encryption software.
Another problem with e-mail is that e-mail technology requires the addition of extra data to all files attached, typically adding about 40% to file sizes, which of course means extra delay in file transfer and extra storage space required on Internet servers. (For example, sending a 1 megabyte file as an e-mail attachment via Microsoft Outlook resulted in over 2 megabytes of total data transmission, including transfer of technical/control data, more than a 100% increase).
In any case, e-mail does not travel in “real time”, it can take minutes, hours or even a day to reach a destination, depending on traffic encountered along the way and on other technical requirements in any of the numerous switches/routers through which a travelling e-mail message must navigate. Also, copies of e-mail messages are routinely taken at these switch points and routinely stored indefinitely, giving rise to fears that they may be susceptible to deciphering by unintended parties at a future time. It commonly happens that the transmission of a large e-mail attachment is interrupted by an e-mail system's administrator, e-mail server manager or telecoms operator, for traffic management reasons, usually automatically by computer decision, and the transmission then must recommence later from the beginning of the message. Occasionally, this happens repeatedly until eventually the message becomes sidetracked and dumped, and therefore never arrives at the desired destination.
Also, while an e-mail message is in transit it is irretrievable by the sender, once it leaves the sender's PC, and is beyond the control of anyone connected with the data, sender or receiver, until it arrives at destination successfully. Many users would feel uncomfortable with that thought if considering sending a vitally important document.
As for web-based e-mail, known as HTML mail, accessible via web-browsers, it suffers the additional disadvantage in that it can be used as a method of carrying out surveillance of recipients and their later correspondents. A web-based e-mail message can easily be imbedded with a tracking device by its sender, so that when the recipient replies to the message, using the “Reply To” button, or forwards the message to a third party, perhaps with another message attached, the original sender receives a secret copy of the forwarded message and all subsequent messages containing the original message as a reference. (This is a weakness of HTML messaging in most of the major e-mail programmes). In other words, systems based on web-based e-mail are unacceptable from a security viewpoint.
When sending data across the Internet most current systems rely exclusively on an intermediate server-based communications system, where the sender and recipient, both clients of the server, transfer their messages through mail servers (if using e-mail technology) or file servers, residing in the system operator's premises or under his control. Typically, files are sent to the recipient's post box on the server, to be later picked up by the recipient. The major problems with this are that servers can become overloaded, especially considering that servers themselves are usually mirrored and backed up/duplicated elsewhere and therefore storage space is usually subject to some limit, and communication bandwidth demand is maximized.
Other providers of Internet-based file management services do not offer a secure, true peer-to-peer (P2P) connection as an option, or if they do, they do not offer a specific security solution and no service other than straight file transfer.
Furthermore, almost all other systems use SSL, or its variants or a similar protocol, such as SSH (or EFTP), for encrypting data between the sender and the server and between the server and the recipient. This is unsatisfactory because a) for many reasons, SSL does not (can not) provide strong encryption; b) SSL encrypts only during transmission and therefore leaves the data in unencrypted form on servers and PCs, where it can be accessed; c) SSL slows down server operations very substantially, including the operations of any intermediate servers (for example if e-mail is used) and therefore transmission and file access times. It is reported that SSL can slow down a server's activity by up to 50 times. To get around this, encryption acceleration hardware can be attached to the server, but, while that rebuilds most of the lost speed, the transfer of the data between the accelerator and the server becomes insecure.
Furthermore, in at least some cases it is probable that the server operator/system provider has access to users' unencrypted data, because of SSL. In any case, a system is badly designed from a security point of view if it decrypts data as it delivers it to the recipient's PC, permitting data to be momentarily unencrypted during an open Internet connection.
SSL uses PKI (public key infrastructure) technology, an encryption system that uses two related encryption keys, one of which is used to decrypt messages encrypted by the other one. This is known as an asymmetric encryption system, as compared to a symmetric system where the encryption and decryption keys are the same. PKI is primarily used as a method of transferring a symmetric system's secret key over the Internet; where there is no other secure way to convey the secret key to a recipient. This is the only benefit of PK systems, which are otherwise less secure and slower, by circa 100 times in the encryption function, than symmetric systems.
A further problem with data encryption in relation to the transfer of data is that normally, if a user wants to share/transfer some encrypted documents to another user, he will first decrypt the data from the really private (disk) password, which normally protects that data, and then re-encrypt it under a password, which he will share with the recipient. (Otherwise, he must needlessly give away/reveal his regular password to another person, whom he might hardly know, and with whom he might never communicate again). But, even in well established symmetric or PKI encryption technologies one does not find the sort of robustness, speed and efficiency that is required for elegant re-encryption or sharing of encrypted data activity.
Another drawback with systems using PKI encryption technology is that they cannot normally handle the sharing of encrypted files among many users. (Each encrypted file in a shared box would have to contain a copy of its unique symmetric key encrypted by the different public keys of each/all users, and all files would have to be modified again for each additional user).
Some file transfer systems, (i.e. such as HushMail (HushMail is a trade mark) system provided by the Hush Communications USA of Austin, Tex.), can encrypt data on the local desktop rather than on the server. The HushMail system, which uses e-mail technology, uses PKI encryption, but keeps users' keys on its server (though in encrypted form), and then downloads to the user his private key inside an “applet”, where the encryption is done, whenever the user needs it. The user must trust that the applet contains no other executable program or other doubtful function, and that his private key is securely managed. The HushMail system does not offer file storage or sharing or other functions.
Most other systems rely exclusively on an intermediate server-based communications system, where the sender and recipient, both clients of the server, transfer their messages through mail servers (if using e-mail technology) or file servers, residing on the system operator's premises or under his control. Typically, files are sent to the recipient's postbox on the server, to be later picked up by the recipient. The major problems with this are that servers can become overloaded, especially considering that servers themselves are usually mirrored and backed up or duplicated elsewhere and therefore storage space is usually subject to some limit, and communication bandwidth demand is maximized.
It is an object of the present invention to overcome the disadvantages of the data management and encryption Internet based systems as hereinbefore described.